Computing applications run using industry-standard, platform-independent technologies such as the Java™ execution environment are often mission-critical for the success of many types of organizations and businesses. As such, ensuring that the applications remain up and running, and in a healthy-enough state to provide desired levels of responsiveness to application workload requests for long periods of time, is a very important responsibility of the organization's IT staff.
Memory management problems can impact an application's responsiveness and longevity. For example, consider a scenario in which a certain amount of memory is allocated or referenced in response to a particular application work request (such as a request for a dynamic web page whose content is generated by an application server), but not all that memory is released or freed after the work corresponding to that request is completed. If this sequence of events is repeated for large numbers of work requests, even if the amount of memory that is not released per request is very small, over time, the server being used for the application may run low on memory (which may lead to slower response times) or even run out of memory entirely (which may result in an application outage). Such problems are referred to as memory leaks. Memory leaks, which can often be the result of subtle programming bugs, especially in high-concurrency applications, are often exhibited even in environments in which automatic garbage collection (GC) is implemented.
Memory leaks are notoriously hard to detect, especially if they are gradual rather than fast. In some cases, enabling instrumentation for memory usage analysis can result in substantial overhead, and hence such an approach may not be practical in production environments. Furthermore, even with such potentially onerous instrumentation enabled, in many cases, it is still hard to identify slow memory leaks, since some of the memory usage changes over time may be the consequence of changes in application workload.